the test passed on https://github.com/SamYuan1990/brpc/actions/runs/13688832022/job/38278130143?pr=33 let me test with 22.04.

https://github.com/SamYuan1990/brpc/actions/runs/13689813245/job/38280860800?pr=34 tested my local github action, it works.

ok, test passed, waiting for maintainer's review and feedback.

LGTM

Perhaps the original author wanted to use the lazy initialization mechanism to reduce memory usage.

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
    static const std::string s = "unlimited";
    return s;
}

const std::string& AdaptiveMaxConcurrency::CONSTANT() {
    static const std::string s = "constant";
    return s;
}

1.This way of initialization is much more common，uncontrolled use of global variables may cause dependency order problems(UB).
2.These short strings can be optimized to be stored on the stack using the SSO(Small String Optimization) mechanism of std::string.
3.The original lazy initialization mechanism is retained to reduce unnecessary memory usage.
4.It is thread-safe.

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
    static const std::string s = "unlimited";
    return s;
}

const std::string& AdaptiveMaxConcurrency::CONSTANT() {
    static const std::string s = "constant";
    return s;
}

1.This way of initialization is much more common，uncontrolled use of global variables may cause dependency order problems(UB). 2.These short strings can be optimized to be stored on the stack using the SSO(Small String Optimization) mechanism of std::string. 3.The original lazy initialization mechanism is retained to reduce unnecessary memory usage. 4.It is thread-safe.

Hi @zhangqiongyu ,

I hope you're doing well! I wanted to check if this is a maintainer change request, as it doesn't seem to be in a CR. I also tried searching via this link but didn't find anything relevant.

I'm relatively new to C++, and I'm here to learn from everyone. If I make any mistakes, please feel free to correct me—I really appreciate it!

I believe we both agree on using const std::string instead of static std::string* s = new to ensure thread safety. However, I'm curious about whether we should use lazy initialization or not. When would be the best time to initialize this variable?

Initially, I considered using the following approach:

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
static const std::string s = "unlimited";
return s;
}

const std::string& AdaptiveMaxConcurrency::CONSTANT() {
static const std::string s = "constant";
return s;
}

But when I realized that the function simply returns a constant string, I thought about making a broader change.

From what I understand, the differences are:

• Defining a const in a class affects the scope of the class and its instances (and possibly all child classes and their instances). It’s unique across all instances.
  
  Regarding memory usage:
  As far as I know, and as mentioned in the PR description, compiler optimization is a bit beyond my current knowledge. Since it's a short string, it might benefit from SSO (Short String Optimization). However, I'm not entirely sure how the compiler will handle it.
  
  I’m aware of the concept of dependency order problems (UB), but I lack practical experience in C++. Could you provide an example in this context?
  
  Regarding performance, when invoking this value from other parts of the code, previously it involved a function call. After changing it to a const, it becomes a direct access to a constant. From my understanding, if the compiler optimizes a function call that returns a static value, it should be equivalent to accessing a constant. If the function isn't loaded onto the stack, it might involve a page change/reload. If SSO is in play, the string would be on the stack in either case (function call or const).
  

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
static const std::string s = "unlimited";
return s;
}


I’d love to hear your thoughts on this! Thank you for your time and guidance. 😊

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
    static const std::string s = "unlimited";
    return s;
}

const std::string& AdaptiveMaxConcurrency::CONSTANT() {
    static const std::string s = "constant";
    return s;
}

1.This way of initialization is much more common，uncontrolled use of global variables may cause dependency order problems(UB). 2.These short strings can be optimized to be stored on the stack using the SSO(Small String Optimization) mechanism of std::string. 3.The original lazy initialization mechanism is retained to reduce unnecessary memory usage. 4.It is thread-safe.

Hi @zhangqiongyu ,  I hope you're doing well! I wanted to check if this is a maintainer change request, as it doesn't seem to be in a CR. I also tried searching via this link but didn't find anything relevant.  I'm relatively new to C++, and I'm here to learn from everyone. If I make any mistakes, please feel free to correct me—I really appreciate it!  I believe we both agree on using const std::string instead of static std::string* s = new to ensure thread safety. However, I'm curious about whether we should use lazy initialization or not. When would be the best time to initialize this variable?  Initially, I considered using the following approach:

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
static const std::string s = "unlimited";
return s;
}

const std::string& AdaptiveMaxConcurrency::CONSTANT() {
static const std::string s = "constant";
return s;
}

But when I realized that the function simply returns a constant string, I thought about making a broader change.  From what I understand, the differences are:

• Defining a const in a class affects the scope of the class and its instances (and possibly all child classes and their instances). It’s unique across all instances.
  
  Regarding memory usage:
  As far as I know, and as mentioned in the PR description, compiler optimization is a bit beyond my current knowledge. Since it's a short string, it might benefit from SSO (Short String Optimization). However, I'm not entirely sure how the compiler will handle it.
  
  I’m aware of the concept of dependency order problems (UB), but I lack practical experience in C++. Could you provide an example in this context?
  
  Regarding performance, when invoking this value from other parts of the code, previously it involved a function call. After changing it to a const, it becomes a direct access to a constant. From my understanding, if the compiler optimizes a function call that returns a static value, it should be equivalent to accessing a constant. If the function isn't loaded onto the stack, it might involve a page change/reload. If SSO is in play, the string would be on the stack in either case (function call or const).

const std::string& AdaptiveMaxConcurrency::UNLIMITED() {
static const std::string s = "unlimited";
return s;
}

 I’d love to hear your thoughts on this! Thank you for your time and guidance. 😊

Hi，It's a pleasure to have a friendly discussion with you.
1.Google's programming standards clearly state that global variables should be used with caution.
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables

2.Dependency order problems (UB). The snippet below is nothing todo with brpc, but what if someone wants to use this global variable in the future?
File1.cpp

#include <iostream>

// Declaration of the global variable in another file
extern int g_var2;

int g_var1 = g_var2 + 1; // Depends on the initialization order of g_var2

void func1() {
    std::cout << "func1: g_var1 = " << g_var1 << std::endl;
}

File2.cpp

#include <iostream>

// Declaration of the global variable in another file
extern int g_var1;

int g_var2 = g_var1 + 1; // Depends on the initialization order of g_var1

void func2() {
    std::cout << "func2: g_var2 = " << g_var2 << std::endl;
}

int main() {
    func1();
    func2();
    return 0;
}

3.About memory usage, lazy initialization is achieved by using functions to return static local variables, which are initialized only when needed, saving unnecessary resource overhead.
4.About performance, I have the same view with you.

In my usual projects, I prefer to use functions. In fact, I have done a lot of performance profiling, and this method has never become a performance bottleneck. Maybe what we are discussing is just some programming habits and trade-offs, but I don't think this will hinder the inclusion of PRs.